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1 Document status 



1.1 Introduction 

This Functional Specification is applicable to the project TransformingLearning.com. 
The Broadband Communications reference is Q1397. Broadband Communications 
Ltd. (herein referred to as BROADBAND) has been contracted by Transforming 
Learning (herein referred to as TLC) to perform the complete project. This document 
identifies the methodology and rationale for the implementation of the project. 

1.2 Authority 

This document was produced by Matt Southall, Rob Ingram and Fiona Conner of 
BROADBAND. The production of the document was sanctioned by Michael Von der 
Geest (Project Manager) of TLC. 

1 .3 Contractual Status 

This document is a deliverable of the contract Q1397 and as such shall be approved by 
both BROADBAND and TLC and is subject to formal change control procedures after 
official release. 



1.4 Associated Documents 



This document relates specifically to: 
Discrete Content Information Summary 
Flowcharts 
Algorithm List 
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Demo Site 



1 Introduction 

The Demo site will be used by TLC as a marketing tool, and will aim to give a "taster" of 
what the finished application will offer. The functionality of the finished application will 
be demonstrated by means of designed screen shots which the user will be "led 
through" via the site navigation. 

This section of the Functional Specification should be read in conjunction with 
Appendix 1 - Demo Site Map and Appendix 2 - Demo Site Content. 

2 Design 

The Demo site will aim to present the essence of the "look and feel" of the finished 
application. It is appreciated that design will progress post-completion of the demo 
site, and that the finished application will in all likelihood look different to some degree. 



3 Functionality 

The following list represents the core functionality of the demo site: 

« The site will consist of a collection of static HTML pages with "screenshots" 
(designed graphics) which will demonstrate the look of the finished application. 

• The functionality of the finished application will be demonstrated as the user follows 
a "presentation" of different user types (Teacher, Headteacher, Schools Advisor). 

• Navigation will be by means of the user clicking links or buttons. 

• Either popup windows which appear when the user moves the mouse over the 
content or static sub-windows will highlight certain pieces of content. 

• The facility will exist for users to ask a question using a form with the fields shown 
below: 

o "What would you like to know?" [Free text] 

o "Priority" [Pull-down menu. Possible values are "Moderate", "Urgent", 

defaulting to "Moderate"] 
o "Your contact details" 

■ "Your Name" [Free text] 

■ "Your E Mail Address [Free text] 

The contents of the form will be directed to TLC via e mail to a mailbox to be 
specified by TLC. 

o Although the content in the demo site will not be data driven, a database will be 
used in order to capture details of users who would like to receive follow up 
information and updates. 

• There will be a feedback form which will reside under the "Keep Me Posted" page 
which will submit to the database. This form will contain the fields given below: 

o "Name" [Free text] 

o 'What is your Role?" [Pull-down menu. Possible values are "Teacher", 

"Headteacher", Schools Advisor"] 
o 'Were do you Work?" [Free text] 
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« [Pull-down menu allied to above question. Possible values are 
"School", Local Education Authority", "Education Action Zone", 
"Other] 

o "Name of Organisation" [Free text] 
o "Your Email Address" [Free text] 

o "I Prefer to be Kept in Touch By" [Pull-down menu. Possible values are "E 

Mail", "Post", defaulting to "E Mail" if field is not blank] 
o "Your Postal Address" 

• "Line 1" [Free text] 

- "Line 2" [Free text] 

- "Town" [Free text] 

« "County 1 ' [Free text] 
■ "Postcode" [Free text] 
o "Do you have any specific comments or questions?" [Free text] 

The hidden "Category 1 ' field will derive its value based on the value the user 
selected for "Role". If the user selected "Teacher", the value will be set to "User", if 
any other user type was selected, the value will be set to "Buyer". 

• It is understood that the data in the database should be in a format compatible with 
an existing marketing database in use at TLC. This will be achieved by ensuring 
that each new record added to the database will add the following values to fields 
"source", "status" and "permission" respectively: 

o website 
o prospect 
o 3 

Technological Constraints 

The Demo Site will be subject to the same Client Specification as the main application, 
notably that it will be designed for browser versions 3 and upward, and that it will 
assume that users have Javascript enabled. Refer to section 8.1 for further details. 

Site Map 

Pages and navigational structure to be incorporated in the Demo Site are detailed in 
Appendix 1 - Demo Site Map and Appendix 2 - Demo Site Content 

Hosting 

The Demo Site will be hosted by an ISP with support for ColdFusion, as this will be 
used in certain sections of the site. TLC are responsible for sourcing the ISP. 
Broadband are responsible for uploading the completed Demo Site, and will require 
FTP access to the chosen ISP in order to accomplish this. 
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3 Functional Breakdown 



3.1 Introduction 

This section will describe each of the functional components of the TLC application. Each 
subsection will outline the main tasks being carried out and the pre and post conditions for 
each element. 

The components that will be described in this section are: 

• Initial Registration 

• Login Control 

• School Manager Creation 

• Set Creation and Rater Nomination 

• Tracking and Rater management 

• Questionnaires, comprising: 

- Questionnaire Completion 

- Individual Questionnaire Processing 

- Individual Questionnaire Data Cleaning 

• Dataset Data Cleaning 

• Data Markers 

• Teacher/Headteacher Feedback, comprising: 

- Theory 

- Context 

- Feedback 

- Emotions 

- Prioritise 

- Investigate and Action Planning 

• School Manager Feedback Calculation 

• School Manager Feedback 

• EA Officer Feedback Calculation 

• EA Officer Feedback 

• User Survey 

• Handling Forgotten Passwords 

• Changing User Passwords 

• Offline Scheduler 



3.2 Initial Registration 
3.2.1 Overview 

Initial registration covers the first attempt of any user to authenticate themselves to the 
system. The user types involved are:- 

• Headteacher 

• Primary Teacher 

• Secondary Teacher 

• EA Officer 

• Adult Rater 

• Primary Student Rater 

• Secondary Student Rater 

This initial authentication will be based on either a simple unique individual ID (for raters) or 
a combination of school/EA ID and individual ID. These IDs will most likely be based on 
alphanumeric strings. A certain number of these strings will be valid as licences for 
particular user types or specified as being particular raters. For a 7-letter string consisting 
of the letters 'a-z' and the numbers '0-9' there are over 78 billion permutations. This would 
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provide for a high degree of security, making licences and rater IDs effectively 
unguessable. 

Only headteacher and rater IDs will be bound to particular institutions before initial 
registration. For other users this will occur when their user record is created. 

Input to this system could be from multiple sources (e.g. Rater registration, EA Officer 
registration, Teacher registration etc). The system will be able to perform appropriate 
registration options based on the input source and the individual ID (which will be flagged in 
the database as being "Headteacher", "EA Officer" etc). School managers do not pass 
through this process as their login details are defined by the headteacher. 

On completion, the registration system will perform a transparent 'login' to the system. 



3.2.2 Inputs 

A unique individual ID (from user) 

An optional school or EA ID (from user) 

3.2.3 Outputs 

Login (redirect to login page and pass in valid details). 

Creation of new user record (for all user types, notably excluding primary rater). 

Username (stored to database for all user types, excluding rater). 

Password (stored to database for all user types, excluding primary student rater). 

Aide memoire question and answer (stored to database for all users with a password in 

case it is forgotten, see section 3.16.) 

Deletion of individual ID (where ID was a licence, excluding rater where the licence will be 
used as a username). 

3.2.4 Process Description 

See chart IR, CONS. This chart is a consolidation of a set of "per-usertype" initial 
registration charts:- 

• IR, EA (Education Administrator) 
« IR, AR (Adult Rater) 

• IR, HT (Headteacher) 

• IR, PT (Primary Teacher) 

• IR, ST (Secondary Teacher) 

• IR, PSR (Primary Student Rater) 

• IR, SSR (Secondary Student Rater) 
All of which are included for reference. 

3.3 Login Control 

3.3.1 Overview 

This subsystem deals with all return visits from users after completion of "Initial 
Registration". Users will be expected to provide both a username and a password in order 
to log in. The system will be able to identify the user uniquely by this username/password 
combination. 

It is anticipated that some users (e.g. primary student raters) will complete all tasks after 
being automatically logged in by the initial registration and will not therefore need to use a 
separate login procedure. This system will nevertheless accommodate login attempts from 
the few exceptions. 

Headteachers and teachers will be asked to complete a short background questionnaire 
the first time they log in (usually immediately after the initial registration process.) 
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3.3.2 Inputs 

A unique username (or individual ID in the case of a rater.) 
A password (except for primary student raters.) 

Note: both of the above are either directly input by user or known implicitly from automated 
login following initial registration. 



3.3.3 Outputs 

User will be authenticated to the system. 
User will be uniquely identifiable. 

Background data on headteachers and teachers stored in the database. 

System will display appropriate page with options currently available to that user, including 

an option to return to the appropriate point in a partially completed task. 

3.3.4 Process Description 

See charts: 

• LIC, ALL 

• BQ, HT & T 

3.4 Create School Manager 

3.4.1 Overview 

Headteachers will be provided with the option of creating a school manager account. This 
will be used to view summary feedback on the school as a whole. The use of this account 
is not necessarily limited to the headteacher and may be shared between members of the 
school. 

This process may also be used to change the details of the school manager account or 
delete it completely. 

3.4.2 Inputs 

User identified as headteacher. 

3.4.3 Outputs 

School manager username and password saved to database, removed from database or 
amended. 

3.4.4 Process Description 

See chart CSM. 

3.5 Create set and Nominate Raters 
3.5.1 Overview 

'Set Creation' is the process whereby a user's 'dataset' is created. A dataset is the set of 
all data pertaining to a particular individual ('self) at a particular time and (for non- 
headteachers) with respect to a particular class. 

The process of creating a new set involves creating a set of new records in the database 
and, in the case of teachers, populating some of these with input from the user's set 
questionnaires. 

In T1 , the first time a user users Transforming Learning in an academic year, all set 
creation will be implicit and transparent to the end user, except that a teacher must name a 
set. The phase one system will automatically create a new dataset for each 'self if they do 
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not already have a dataset created (a prerequisite for any questionnaires etc.) Where 
necessary the system will present appropriate background questionnaires based on the 
user type. 

This process also involves the nomination of the raters who are to answer the 
questionnaires belonging to this dataset. The user will enter the name and email address (if 
available) of the raters and the system will generate a unique identifier for each. This ID will 
either be emailed to the rater or, if no email address is available, made available in a 
printable format. Once raters have been nominated the user will be asked to set a deadline 
by which they must have completed their questionnaires. 

In T2 newly created sets will be matched to a particular set from T1 . The user will have the 
option of using the same raters from T1 in 12 or nominating new raters. Users will also 
have an opportunity to amend their background questionnaire data to reflect changes in 
their circumstances. This subsystem must provide the user with the facility to select any of 
their datasets in order to view the appropriate feedback, tracking data etc. 

3.5.2 Inputs 

Unique authenticated user. 

3.5.3 Outputs 

Empty dataset ready for population with raters, questionnaire data etc. (In T2 linked to 

appropriate T1 dataset.) 

Rater IDs created and saved in database. 

Email sent to raters if address available. 

Printed rater details if requested. 

Deadline for questionnaire submissions set. 

3.5.4 Process Description 

See charts: 

• CSNR, T 

• CSNR, HT 

• CSNR, T2 

• CSNR, HT2 

3.6 Tracking and Rater Management 

3.6.1 Overview 

The tracking system will provide an overview of the user's progress. A single screen will 
show which questionnaires have been completed and by whom (self or which rater) as well 
as details concerning what stage the user has reached on the path through theory, 
feedback and action planning etc. The display will highlight potential problems such as 
questionnaires not near completion as deadlines approach or raters who have not yet 
registered on the system after a given period of time has elapsed since their nomination. 
The deadline for questionnaires to be completed may also be changed within this process. 

If a rater has been rejected for any reason during the process of questionnaire completion 
and processing the user will be given the option to replace that rater. This will follow the 
same format as the rater nomination described in section 3.5.1. 

Where a user has more than one dataset, tracking information would be dataset specific, 
i.e. the user would have to explicitly select a different dataset (e.g. from a dropdown) in 
order to see the tracking information for that set. 

3.6.2 Inputs 

Unique user. 
Dataset identified. 
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3.6.3 Outputs 

Tables showing progress of self and raters through process for this dataset. 

Rejected raters replaced. 

Questionnaire deadline reset if required by user. 

3.6.4 Process Description 

See chart TR, CONS. 



3.7 Questionnaires 



3.7.1 Overview 

This section details the three modules involved in collecting and processing individual 
questionnaire submissions for self and raters. These processes are distinct from those 
used to collect background data etc. There are several different questionnaire types 
covered by this system:- 

• Headteachers Context For School Improvement (Climate) 

• Headteachers Leadership Styles 

• Classroom Climate (Primary Schools) 

• Classroom Climate (Secondary Schools) 

3.7.2 Questionnaire Completion and Initial Validation 

3.7.2.1 Overview 

This system presents a set of questions to the user and records their answers. For 
teachers, the set of questions presented may be altered according to data gathered in the 
set questionnaires (e.g. some questions will not be appropriate for teachers who do not 
have a classroom and/or do not set homework.) 

Adult raters are asked a question about their knowledge of the headteacher's performance. 
If they do not fulfil the criteria they will be rejected before they start filling in the 
questionnaires. 

The process will also include some initial data validation, primarily checking for incomplete 
question pairs (where the question requires actual and ideal values) and large numbers of 
unanswered questions. In the former case the system will insist that both parts of the 
question pair be filled in. In the latter case the user will be prompted to answer more 
questions but the questionnaire will be accepted provided that less than 20% of questions 
are blank. 



3.7.2.2 Inputs 
Identified user type. 
Data set identifier. 

Relevant questions identifier (e.g. homework questions) 

3.7.2.3 Outputs 

Raw data for questionnaire recorded to dataset in database. May be partial data if the 
questionnaire has not been completed. 
Completion status of questionnaire altered. 

3. 7.2.4 Process Description 
See charts: 

• COQ, HT1 (Headteacher Climate) 

• COQ, HT2 (Headteacher Leadership) 

• COQ, PT (Primary Teacher) 

• COQ, ST (Secondary Teacher) 

• ROQ, AR1 (Adult Rater Climate) 

• ROQ, AR2 (Adult Rater Leadership) 
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• ROQ, PSR (Primary Student Rater) 
ROQ, SSR (Secondary Student Rater) 

Algorithms: 

QBb1 to QBb4 
QBa2 

• QBa3 

• QAc7 

• QBc2 
o QBc3 

QAd7 

QBd1 to QBd4 
QBf2 

• QBf3 

• QBe2 

• QBe3 

• QAg1 
QBg2 

• QBg3 
QAh1 
QBh2 
QBh3 

3.7.3 Individual Questionnaire Data Cleaning 

3.7.3.1 Overview 

Questionnaire data cleaning is an overnight process performed whilst load on the system is 
low. This event occurs if all questionnaires in a users' set are flagged as complete, i.e. 
both the climate and leadership styles questionnaires must be complete for headteachers 
or those rating headteachers, otherwise just the climate questionnaire must be complete. 

Depending on the type of questionnaire the cleaning process might include: checking that 
the data are not overly biased towards one end of the scale, checking that the user has 
recognised reversed questions and confirming that an adequate number of the questions 
have been answered. Data may be rejected if any of these tests fail. 

3.7.3.2 Inputs 

Validated questionnaire data for self or rater. 

3.7.3.3 Outputs 

Cleaned questionnaire data that is ready for processing. 

If data fail tests: flag for rejected data and email to self indicating a rejected rater. 

3. 7. 3. 4 Process Description 
See charts: 

IQC, AR1 (Adult Rater Climate) 

• IQC, AR2 (Adult Rater Leadership) 

• IQC, PSR (Primary Student Rater) 

• IQC, SSR (Secondary Student Rater) 

Algorithms: 

QCfl to QCf3 

QCe1 

QCe2 

QCg1 

QCg2 

QCh1 to QCh3 
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3.7.4 individual Questionnaire Processing 

3.7.4.1 Overview 

Questionnaire data processing is an overnight process performed whilst load on the system 
is low. This event occurs if a questionnaire set (both climate and leadership styles, if 
applicable) is flagged as cleaned ready for processing. 

This system takes the clean data for an individual questionnaire and calculates summary 
values for each dimension and leadership style. It will also perform some calculations in 
relation to national norms where appropriate. 

3.7.4.2 Inputs 

Clean questionnaire data for self or rater. 

3.7.4.3 Outputs 

Processed dimension/leadership styles values for the individual questionnaire saved to 
database. 

3. 7. 4. 4 Process Description 
See charts: 

IQP, HT (Headteacher) 

• IQP, PT (Primary Teacher) 

• IQP, ST (Secondary Teacher) 

• IQP, AR (Adult Rater) 

• IQP, PSR (Primary Student Rater) 

• IQP, SSR (Secondary Student Rater) 

Algorithms: 
QDb1 
QDb2 

• QDa1 to QDa3 
QDd 

QDc2 
QDd1 

• QDd2 
QDft 
QDf2 

• QDe1 to QDe3 
QDg1 

QDg2 
QDh1 

• QDh2 



3.8 Dataset Data Cleaning 
3.8.1 Overview 

Dataset data cleaning is an overnight process performed whilst load on the system is low. 
The event occurs when the questionnaires of all raters for a given dataset have been 
processed or if enough raters' questionnaires have been processed and the 'self indicates 
that they wish to initiate the process. The data relating to the user's own questionnaire are 
not included in this process. 

Dataset cleaning involves a number of per-dimension or per-leadership style calculations 
across the data for all raters. Checks are then carried out on the results of this processing 
with a number of possible outcomes. These include: the rejection of scores for an individual 
rater for an individual dimension or flagging of dimensions as being outlying or skewed. 
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3.8.2 Inputs 

Processed dimension/leadership styles data for n raters of the current dataset. 

3.8.3 Outputs 

Clean pre-processed data for all dimensions/leadership styles across raters. 
Flags indicating outliers and skewed data. 

3.8.4 Process Description 

See charts: 

• SQC, AR1 (Adult Rater Climate) 

• SQC, AR2 (Adult Rater Leadership) 

• SQC, PSR (Primary Student Rater) 

• SQC, SSR (Secondary Student Rater) 

Algorithms: 

QEf1 to QEf8 

QEf9 
« QFf1 

QFf2 

• QEe1 to QEe3 

• QEe5 to QEe7 

• QEe9 

• QFe1 to QFe4 

• QEg1 to QEg8 
QEg9 

• QFg1 

• QFg2 
QFg4 

QEh1 to QEh8 
QEh9 

• QFh1 

• QFh2 

3.9 Data Markers 

3.9.1 Overview 

Once questionnaire data is valid, clean and pre-processed (skew and outlying values 
flagged) it will be ready for processing to create the data markers. These markers are 
calculated according to algorithms specified by Hay and are used to control the feedback 
process. Once these markers are calculated, the raw data should no longer be needed 
and will be archived (for Hay and in case re-calculation is necessary at a later date). 

The process then acts on a set of clean questionnaire data and markers to produce a 
number of graphs that will be presented to the user as feedback. The graphs will broadly 
illustrate the user's score in relation to population norms and comparisons between actual 
and ideal aspects of their own data and between their own data and that of their raters. In 
the initial version the graphs will be generated as GIF files. 

In T2 additional processing will be carried out to produce comparisons between data in T1 
and T2. 

The data marking process will be carried out off-line and the graphs generated will be 
stored to be presented to the user during Feedback. In order to reduce resource 
consumption all graphs will be kept for a period of one month (or specified period), after 
which they will be removed from the server. If a user attempts to view their feedback after 
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this period the graphs will be re-generated for immediate presentation and again stored for 
a period of one month. 

3.9.2 inputs 

Complete valid, clean and pre-processed dataset. All the data necessary for processing will 
be present in the database. 

3.9.3 Outputs 

Complete set of data markers for that dataset. 

GIF files containing graphs illustrating the results of the questionnaire processing. 

3.9.4 Process Description 

See charts: 

• DM, HT (Headteacher and Adult Rater) 

• DM, PT (Primary Teacher and Student Rater) 

• DM, ST (Secondary Teacher and Secondary Student Rater) 

Algorithms: 

• QGa1 to QGa3 

• QGa6 to QGa9 
QGb1 toQGb13 

• QGc1 to QGc9 
QGd1 toQGd13 

3.10 Teacher/Headteacher Feedback 

3.10.1 Overview 

The feedback system presents to the user a summary of the analysis of questionnaire 
results for a given dataset. This will relate to their own questionnaires and those of their 
raters with comparisons to national norms where appropriate. 

3.10.2 Theory 

3.10.2.1 Overview 

The theory section of the feedback process is designed to help the users to properly 
interpret the data that they will receive by providing familiarisation with the process and 
background to the theory of the evaluation model being used. Participants will be lead 
through a combination of explanatory screens, with various levels of detail being provided if 
they wish to drill down, and case studies with simple interaction capabilities, in addition 
background information will be provided on the way in which people respond to feedback 
and the opinions of others. 

Most of the definitions and explanations provided will be made available for users who wish 
to refer back to them during later stages of the process. 

Once the subsection has been completed the users will be advised to pause in order to 
assimilate the information they have been given before continuing with their feedback. 
Completion of this process is mandatory before further feedback will be provided. However, 
users may return to refresh their knowledge of the theory at any point 

In T2 the information presented to the user during the model explanation and case studies 
will differ to take account of the comparison between T1 and T2 data. 

3.10.2.2 Inputs 
User identified. 

Flag showing whether theory has already been completed by this user. 
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3.10.2.3 Outputs 

Completion of the theory section is flagged to the system so that the user is allowed to 
continue with feedback. 

On first completion if the user's feedback is not ready they are informed that they will be 
notified when they may proceed with the process. Otherwise the user is advised to take a 
break before moving on to their feedback. However, this is not enforced and if the feedback 
is ready the user may pass directly on. 

3. 10.2.4 Process Description 
See charts: 

TH,T1 (Teacher, T1) 

• TH, T2 (Teacher, T2) 

• TH, HT1 (Theory Headteacher, T1 ) 
TH, HT2 (Theory Headteacher, T2) 

• CASE, HT1_1 (Case Studies Headteacher, T1) 

• CASE, HT1_2 (More Case Studies Headteacher, T1 ) 

• CASE, HT2JI (Case Studies Headteacher, T2) 

• CASE, HT2__2 (More Case Studies Headteacher, T2) 



3.10.3 Context 

3.10.3.1 Overview 

This subsection will gather data on what is happening in the user's environment and what 
aspects of their work they wish to change and improve in the near future. It takes the form 
of a short introduction and an exercise where the user input is actually gathered. 

3.10.3.2 Inputs 

User identified and has completed theory. 

3.10.3.3 Outputs 

Incidents exercise answers saved to database. 
Aspiration text gathered if not already completed. 

3. 10.3.4 Process Description 
See charts: 

• CON, T1 , T2 (Teacher, T1 & T2) 

• CON, HT1 , HT2 (Headteacher, T1 & T2) 

3.10.4 Feedback 

3.10.4.1 Overview 

In this subsection the user is presented with their personalised feedback based on the 
analysis of their own questionnaires and those of their raters. They are introduced to the 
feedback process and then presented with each of the graphs generated in Section 3.9 in 
turn for each dimension and leadership style (for headteachers.) The graph will be 
accompanied by text annotations that are drawn from the database based on the results 
currently being displayed. The order in which the dimensions/styles are presented will be 
determined algorithmically. At the end of each dimension and style user reaction data, 
prioritisation and reflective text will be gathered and stored in the database. 

After all dimensions and styles have been presented individually a summary will be 
provided comparing the rater's actual to ideal scores and the user's overall results to 
population norms, again accompanied by appropriate text. The user will then input 
reactions to the summary data. 
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Throughout the process the user will also be able to enter textual notes into a jotter that will 
be stored in the database. 

In 12 additional charts will be shown for T1-T2 comparisons. 

3.10.4.2 Inputs 

User completed incidents exercise from context. 

3.10.4.3 Outputs 

Free text reflections, DAWA option selection and priority selection for each 
dimension/leadership style saved to database. 

Free text reflections and DAWA option selection for summary saved to database. 
Jotter data to database. 

3. 10.4.4 Process Description 
See charts: 

• FEED, PT1 (Primary Teacher, T1) 

• FEED, ST1 (Secondary Teacher, T1 ) 
FEED, HT1_1 (Headteacher Climate, T1 ) 

• FEED, HT1_2 (Headteacher Styles, T1 ) 

• FEED, PT2 (Primary Teacher, T2) 

• FEED, ST2 (Secondary Teacher, T2) 
FEED, HT2_1 (Headteacher Climate, T2) 

• FEED, HT2_2 (Headteacher Styles, T2) 

Algorithms: 
TF1 

• TF2a 

• TF2b 
TF3 
TF4 

• TF12 

• TF14 
TF13a 
TF13b 

. TF1(2) 

• TF2a(2) 
TF2b(2) 

• TF13a(2) 

• TF13b(2) 
TF14(2) 

• HF1 

• HF2a 

• HF2b 

• HF3 

• HF4 
HF5 

• HF6a 

• HF6b 
HF12 
HF1(2) 
HF2a(2) 
HF2b(2) 
HF5(2) 
HF6a(2) 
HF6b(2) 
HF12(2) 
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3.10.5 Emotions 

3.10.5.1 Overview 

The emotions section of feedback is designed to summarise the user's reactions to the 
previous feedback section and allow them to start thinking about how they may begin to 
address any issues that have arisen. Users are presented with an algorithmically produced 
matrix showing their reactions to each dimension or leadership style and an assigned 
priority. They will be allowed to change their reaction (on reflection) or the priority values 
and may drill down for more information on various aspects of the matrix. 

3.10.5.2 Inputs 

Feedback section complete and DAWA and priority values gathered. 

3.10.5.3 Outputs 

Revised DAWA values and priority values per dimension/style saved to database. 

3. 10.5.4 Process Description 
See charts: 

• CRY, T1 (Teacher, T1) 
CRY, T2 (Teacher, T2) 
CRY, HT1 (Headteacher, T1) 
CRY, HT1 (Headteacher, T2) 

Algorithms: 
o TF3 

TF5 

TF9 

HF3 

HF9 



3.10.6 Prioritise 

3.10.6.1 Overview 

This section presents a matrix similar to that of section 3.10.5 but without the DAWA or 
priority values. It provides a mechanism for the user to narrow down the focus of their 
prioritisation prior to action planning. They will be asked to select a number of dimensions 
or styles that have issues that they wish to work on immediately. The system will 
algorithmically check if they have set a reachable target and advise them if they have not. 
The matrix will also provide access to more detailed background information on the 
dimensions in relation to their own context. 

In T2 additional algorithms will be used to help users build on their work from T1. 

3.10.6.2 Inputs 

Table of values from 3.10.5. 

3.10.6.3 Outputs 

Subset of dimensions/styles chosen for further action. 

3. 10.6.4 Process Description 
See charts: 

• PRI,T1 (Teachers, T1) 

• PRI, T2 (Teachers, T2) 

PRI, HT1 (Headteachers, T1) 
PRI, HT2 (Headteachers, T2) 

Algorithms: 

• TF4 
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• TF6 

• TF7 

• TF14 

• HF4 

• HF10 

• HF11 
HF13 



3-10.7 Investigate and Action Planning 

3.10.7.1 Overview 

The final phase of feedback is a process of providing information on the competencies 
required for each of the dimensions selected in section in section 3.10.6 and assigning 
dates and resources to actions required to make improvements in the desired areas. 

The user is presented with a matrix of their chosen dimension. For each dimension they will 
then be lead through detail of the competencies. Headteachers will additionally be lead 
from a dimension to the relevant leadership styles, each of which have an associated set of 
competencies. At each stage they can select from set action points to save to the action 
planner or can input as free text their own actions. When ail dimensions have been 
completed the user is shown a table of actions, populated by their earlier choices or text 
input, to which they may assign dates, resources and priorities or add more actions. 

In T2 additional algorithms will be used to help users reflect and build on their progress 
since T1. 

If after a given time has passed since investigation was completed no actions have been 
posted to the action planner the user will be sent a reminder email. Actions will be flagged 
as major and minor tasks. Email reminders will also be sent as major actions become due. 

3.10.7.2 Inputs 

Prioritised dimensions from previous section. 

3.10.7.3 Outputs 

Competency (and style for headteachers) options and text (for action planning matrix) to 
database. 

Action plan data to database. 
Email reminders (see Appendix 7.) 

3. 10.7.4 Process Description 
See charts: 

VEST, T1 (Teachers, T1) 

• VEST, T2 (Teachers, T2) 

VEST, HT1 J (Headteachers, Styles, T1) 

• VEST, HT1_2 (Headteachers, Competencies, T1) 

• AP, HT1 (Headteachers, Action Planning, T1) 
VEST, HT2 J (Headteachers, Styles, T2) 

• VEST, HT2J2 (Headteachers, Competencies, T2) 

• AP, HT2 (Headteachers, Action Planning, T2) 

Algorithms: 
HF7 
HF14 
HF14(2) 
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3.1 1 School Manager Feedback Calculation 



3.11.1 Overview 

This is a weekly process run during the night that calculates summary data for all teachers 
within a school. It also calculates historical data if appropriate and data for individual 
subjects and key stages. 

3.11.2 Inputs 

Data available for a specified number of teachers. 

3.11.3 Outputs 

Processed data and charts for summary data, key stages and subjects. 

3.1 1 .4 Process Description 

See charts: 
SQC, SM 

Algorithms: 

SM24 to SM44 



3.12 School Manager Feedback 

3.12.1 Overview 

The school manager feedback process has two sections. The first is an introduction to the 
theory of the feedback model similar to that detailed in section 3.10.2. The second displays 
charts containing summary data for the school and more detailed breakdowns by subject or 
key stage. Data are presented as charts and are accompanied by suggestions for possible 
actions to address potential problems. 

3.12.2 Inputs 

School data available. 

3.12.3 Outputs 

3.12.4 Process Description 

See charts: 

TH_SM1_SM2 (Theory, T1 & T2) 
FEED, SM1 (Feedback, T1) 
FEED, SM2 (Feedback, T2) 

Algorithms: 
SM1 
SM2 

• SM8 to SM23 

3.13 Education Authority Officer Feedback Calculation 

3.13.1 Overview 

This is a weekly process run during the night that calculates summary data over a number 
of registered schools, subjects and key stages within the education authority. It also 
calculates historical data if appropriate and data for individual schools. 



Paqe 23 of 50 



3.13.2 Inputs 

Data available for a specified number of schools. 



3.13.3 Outputs 

Processed data and charts for summary data, key stages and subjects. 

3.13.4 Process Description 

See charts: 

• SQC, EA1 

• SQC, EA2 

Algorithms: 

• EA27 to EA50 

3.14 Education Authority Officer Feedback 

3.14.1 Overview 

The EA officer feedback process has two sections. The first is an introduction to the theory 
of the feedback model similar to that detailed in section 3.10.2. The second displays charts 
containing summary data for the schools within the education authority. The officer may 
view data by school, subject or key stage with each option presenting a chart of averages 
and suggestions for possible routes for improvement. 

3.14.2 Inputs 

EA officer feedback calculated. 

3.14.3 Outputs 

3.14.4 Process Description 

See charts: 

TH, EA1 & EA2 
FEED, EA1 
FEED, EA2 

Algorithms: 

EA1 to EA26 
EA51 

3.15 User Survey 

3.15.1 Overview 

This process comprises two surveys carried out on a random number of users of the 
system - once following completion of a questionnaire and once following completion of 
action planning. They ask a few short questions regarding each part of the process. 

The randomisation of recipients is as follows: 
every 100 th teacher 
every 50 th headteacher 
every 50 th school manager 
every 1 0 th education authority officer 

For questionnaire completion in addition to the above: 
every 300 th adult rater 
every 300 th secondary student rater 
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3.15.2 Inputs 

Follow on from feedback and if selected. 



3.15.3 Outputs 

Answers to 6 post questionnaire questions, mixture of options and free text, stored to 
database. 

Answers to 6 post action planning questions, mixture of options and free text, stored to 
database. 



3.15.4 Process Description 

See chart: 
US 

Algorithms: 

UQ1 to UQ4 



3.16 Forgotten Passwords 

3.16.1 Overview 

This subsystem is designed to handle many of the situations where users forget their 
passwords before the need to escalate to the helpdesk. This facility will not be able to deal 
with users who forget both their password and their username but it is anticipated that this 
will be a rare occurrence because users will be allowed to choose their own unique 
username. The basis of the process is the aide memoire question that the user entered 
during the initial registration phase. In the event of a failure to respond correctly to the 
question, or the input of an invalid username, the user will be referred to the telephone 
helpdesk. 

3.16.2 Inputs 

A unique username (or individual ID in the case of a Rater.) 
Aide memoire question and answer. 

3.16.3 Outputs 

The old password will be replaced with a new value. 

3.16.4 Process Description 

See chart FP, ALL. 

3.17 Change Passwords 

3.17.1 Overview 

This process allows users to change their passwords to maintain security. Raters and 
school managers are not allowed to change passwords using this mechanism. The school 
manager password may be changed by the headteacher. 

3.17.2 Inputs 

A unique and valid username and password. 
Aide memoire question and answer. 
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3.17.3 Outputs 

The old password will be replaced with a new value entered during the process. 

3.17.4 Process Description 

See chart CP. 

3.18 Offline Scheduler 

3.18.1 Overview 

The offline scheduler lists pre-scheduled and system events. These will be triggered 
either by time (e.g. questionnaire has not been submitted 2 weeks prior to the deadline) 
or by event (e.g. rater was not appropriate). Refer to Appendix 7 - Scheduled Events 
for a full list of events and triggers. 
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4 Data Structures 

4.1 Data Dictionary 

This section will describe the data structures to be used to store the dynamic elements 
of the application. These fall into four broad categories that overlap in various areas. 
The categories are: 

• User data, including user and institutional data (schools and LEAs.) 

• Instrument data - elements describing functional components of the system 
such as questionnaires, questions and dimensions 

• Dataset data - elements relating to a single dataset such as a group of 
questionnaire responses and associated processed results 

• Feedback data - closely related to dataset data, elements to be used in the 
presentation of feedback to the user and to store data entered by the user. 

The elements will be listed and described in a data dictionary and their relationships 
defined in associated high level Entity Relationship Diagrams (these can be found in 
Appendix 5 - Entity Relationship Diagrams). 



4.2 Data Dictionary Table 





Entity 


Main Fields 


Description 


1 leaf Plra+^a 

This section 
describes data 
relating to 
individuals 
accessing the 
system and their 
institutions. It 


Licence 


in 

User type 


unique iu to lueniiiy users ot 
the system. Pre-generated 
and assigned to a particular 
user type. Only headteacher 
and rater IDs are associated 
with particular users before 
initial registration. All IDs 
except rater are destroyed 
during initial registration. 


includes only 
data that will not 
change greatly 
over time. 


Self/manager 


Username (ID) 
Password ; 
Name 
Usertype 

AM question . 

AM answer 

Background 

; q uestion naire data, 


Data pertaining to individual 
users of the system gathered 
during initial registration and 
first login. For teachers and 
managers (school and EA) 
the initial licence ID is 
replaced with; a user defined 
username. Raters will retain 








Rater ; • 


Licence ID 
[Password] 
Name 
User type . 
[AM question 
AM answer] 
Background 

questionnaire data 
Validity? 


their licence ID as username 
and primary raters not will be 
allowed to enter a password. 
All users that have a 
password will be asked for an 
aide memoire question :and 
answer in case they forget the 
password. The entities will be 
combined into a single User 
entity but have been 
separated out here to 
highlight the differences 
between the raters and other 
users. 




School 


ID 

Name 
Address... 


Static data identifying a 
school. 
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Entity 


Main Fields 


Description 




OLri 1UUI UdldoUL 


in 

Date 


ournmary uaia across a single 
school. 




EA 


ID 

Name 
Address 


Static data identifying an 
education authority. 




EA Dataset 


ID 

Date 


Summary data across all 
(registered) schools in an EA. 




Instrument 
Data 

This section 
describes a set 
of entities that 
hold core data 
that are used to 
define functional 
elements of the 
system. 


User type 


ID 

Value 


The permissible types of user. 
Currently defined as: Head, 
Teacher, Rater, Education 
Officer and School Manager. 
Sub types will be implied from 
background data. 


Questionnaire set 


User type ID 
Questionnaire ID 


Definition of the relationship 
between user types and 
individual questionnaires. 


Questionnaire 


ID 

Introductory text 


Definition and description of a 
Questionnaire includinn a 

V^UWOIIUI 11 1 C4 1 1 v» 1 1 1 ulUU Illy CI 

description. 




Question 


ID 

Text 
Scale ID 
Type 


An individual question to be 
used on one or more 
questionnaires. Should define 
the text of the question and 
refer to the scale it should 
use. Also points to its 
now/ideal pair. 




Qn scale 


Range 


A scale to be associated with 
a question. 




Scale point 


ID 

value 
Text 


A point on a scale and its 
associated text. 




uimension 


in 

ID 

Questionnaire ID 

Name 

Description 


Definition of a dimension 
within a questionnaire. 
Dimensions are associates 
with one and only one 
questionnaire and each 
questionnaire must contain at 
least one dimension. 




Dimension 
questions 


Dimension ID 
Question ID 
Order 
Pair 
Weight 


Definition of the relationship 
between questions and 
dimensions. This entity also 
defines attributes of the 
questions that may be specific 
to the questionnaire 
associated with the 
dimension. Initially these are: 
scale reversal, actual/ideal 
pairing and question weight 
(for possible future use.) 




Control parameter 


ID 

Value 


A parameter to control an 
algorithm. 
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Fntitw 
ciiiiiy 


iviain rieius 


uescnpuon 




Norms 


Dimension ID 
Value 


Set of values describing 
national norms to be used for 
comparison during the 
feedback process 




Competency 


Dimension ID 
Option value 
Text 


Definition of a competency 
associated with a dimension 




Dataset Data 

This section 
describes 
entities forming 
the dataset that 
is associated 
with one pass 
through the 
questionnaire 
process for a 
user. A dataset 
will be for either 
T1 or T2 and, for 
teachers, 
associated with 
a particular 
class. 


Dataset 


ID 

User ID 

Date 

Status 


Definition of a dataset 
containing its unique ID, the 
ID of its owner, creation date 
and status. 


otaius lype 


otatus ID 
Value 


otatus value to oe associated 
with various tasks, e.g. not 
started, started but not 
complete, complete. 


Questionnaire raw 


ID 

Dataset ID 

I Icor in 

user iu 

Questionnaire ID 
Status 
Save point 
Answer values 
Validity? 


Definition of a raw dataset as 
entered by self or rater. 


Question answer 


Questionnaire ID (raw 
or recoded) 
Question ID 
Value 


Actual answer value for an 
individual question. 




Questionnaire 
recoded 


IU 

User ID 
Recoded data 
Dimension averages 


Questionnaire after recoding 
of reversed questions. 




Bookmarker 


User ID 
Task 
Status 
Bookmark 


Record of the status of a task 
assigned to an individual. Also 
stores a bookmark so that a 
user returning to a half- 
completed task may resume it 
at the relevant point. 




Dimension data 


Self average 

ideal/actual 
Rater average 

ideal/actual 
Marker 
Gap? 

Dimension ORL flags 
Rater ORL flags 
Dimension skew flags 
Chart ID 


Final processed data to be 
used in the generation of 
charts for feedback. Contains 
mean values for the 
dimension in question plus the 
gap values and data on ORLs 
and skew. Also includes a 
reference to the chart if it 
exists. 




Chart 


ID 

File ref. 


A chart for a given dimension. 
Contains a reference to the 
physical file for the chart. 




User background 


Variable user data 


Data about a user that may 
vary between datasets. 
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Entity 


Main Fields 


Description 


Feedback Data 

These entities 
form part of the 
dataset data but 


Aspiration 


Dataset ID 
Text 


User aspiration text Bk2 or 
B16b. 


Incidents exercise 
data 


Dataset ID 
Options 


Answer to incidents exercise 
Bk3 orB16d. 


are significant 
enough to 
warrant a 
separate 
description. 
They relate to 
the data that are 
related to or 
collected during 
the feedback 
process. 


Reflective 
questions - 
dimension 


Dataset ID 
Dimension ID 
Text 


Text for per-dimension 
reflective questions. 


DAWA- 
dimension 


uataset id 
Dimension ID 
DAWA value 


Value for per-dimension 
DAWA option. 


Priority 


Dataset ID 
Dimension ID 
Priority level (h, m, 1) 


Priority associated with a 
dimension for action planning 


Memory pad 


Dataset ID 
Dimension ID 
Text 


Textual notes made during 
the feedback process 




Reflective 
question - norms 


Dataset ID 
Text 


Text answers to reflective 
questions based on the 
comparison of user's data with 
national norms 




DAWA - norms 


Dataset ID 
DAWA value 


DAWA values for user's 
reaction to comparison with 
national norms 




Action 


Dataset ID 
Dimension ID 
Completion date 
Resources 
Priorities 
Status 


Action to be carried out for 
prioritised dimension. 
Reference to dataset and 
dimension and data related to 
the completion of the action 
such as time scale, resources, 
priorities and status. 




Style reaction 


Dataset ID 
Dimension ID 
Reaction (yes/no) 


Yes/no answer to whether the 
headteacher is surprised by 
the leadership style identified. 




Style emotional 
reaction 


Dataset ID 
List of styles 


Leadership styles to which the 
head had an emotional 
reaction. 




Action plan follow- 
up 


Action ID 
Text 


Textual description of the 
user's progress towards 
fulfilling their actions from the 
T1 plan. 




Gap type 


Gap 
Value 


Types of gap that may be 
associated with particular 
numerical values. 




Dimension text 
selection matrix 


Independent variables 
Code 


Matrix to choose text for 
feedback for the given 
dimension based on a number 
of independent variables. 




Dimension text 
matrix 


Code 
Text 


Text to be displayed for 
dimension feedback. 




Dimension 

independent 

variable 




Independent variable forming 
part of key in dimension text 
selection matrix. 
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Entity 


Main Fields 


Description 




Dataset text 
selection matrix 


Independent variables 
Code 


Matrix to choose text for 
feedback for the given dataset 
based on a number of 
independent variables. 




Dataset text 
matrix 


Code 
Text 


Text to be displayed for 
dataset feedback. 




Dataset 

independent 

variable 




Independent variable forming 
part of key in dataset text 
selection matrix. 




Comparison text 
selection matrix 


Independent 
Code 


Matrix to choose text for 
feedback for the given 
comparison based on a 
number of independent 
variables. 




Comparison text 
matrix 


Code 
Text 


Text to be displayed for 
comparison feedback. 




Comparison 
independent 
variable 




Independent variable forming 
part of key in comparison text 
selection matrix. 




Phases text 
selection matrix 


Independent variables 
Code 


Matrix to choose text for 
feedback for the given phases 
based on a number of 
independent variables. 




Phases text 
matrix 


Code 
Text 


Text to be displayed for 
phases feedback. 




Phases 

independent 

variable 




Independent variable forming 
part of key in phases text 
selection matrix. 




Overall text 
selection matrix 


Independent variables 

Code 

Norms 


Matrix to choose text for 
feedback for the given dataset 
based on a number of 
independent variables and 
norm values. 




Overall text matrix 


Code 
Text 


Text to be displayed for 
climate overall feedback 
(teachers). 
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5 CPS 

5.1 Overview 

Broadband licence a custom built Content Production System (CPS). 
Unlike many such systems, the Broadband CPS is a complete site management 
system including a multi-user 'permissions' system. This allows full control over who 
may or may not edit or publish any of the content on a web site. 

Our objectives have been to produce a tool with the following characteristics:- 

• Enable non-technical staff to perform administrative tasks 

• Minimise need for technical intervention 

• Present a familiar and intuitive user interface 

• Provide a WYSIWYG' interface where appropriate 

• Enable production and editing of web site content 

• Enable production and editing of 'meta data' (e.g. keywords etc) 

• Enable general administration of web site 

• Enable 'super user' administration of management system itself (e.g. user 
management etc). 

The primary interface through which users are able to edit and publish content is 
designed to be familiar and intuitive to non-technical staff who are already used to 
using a desktop environment such as Windows and a web browser such as Internet 
Explorer. Users are presented with an "Explorer" style tree control in a pane on the left 
of their browser and a selection of different screens in another pane to its right. 

The screen below shows a user editing an existing page within the site. The left hand 
pane has been used to select the desired page from the site 'tree'. The user then 
clicked on an 'edit' button below the tree and a set of input fields appeared on the right 
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hand side. These input boxes ailow the user to control both the content of the page 
(via the WYSIWYG editor near the bottom of the page) as well as meta-data e.g. 
keywords (for search engines), dates (for diary events), categorisation (for enabling a 
more user-centric navigation, presenting users with links to 'related content'). 

Once the user is happy with the edited version they can click 'submit' and the system 
will render a preview of the page exactly as it would appear in the site. If the user is a 
'publisher' they will then have the option to make this page live on the site. If the user 
is an 'editor', they will be given the option to submit this page for the approval of an 
authorised publisher. The live site would not allow such a 'proof page to be displayed 
to site visitors until it had been published by an authorised user. 

The system has evolved beyond a simple 'page' management system into a generic 
database administration tool for non-technical staff. Individual nodes in the tree control 
need not represent entities at the 'page' level but rather may represent any item of or 
collection of data within the system. For example, within the TransformingLearning 
project, there might be folders representing Questionnaires and these folders might 
contain individual nodes which represent questions. These questions could then be 
changed individually without resorting to low level access to the database. 

The Broadband CPS accomplishes this by relying on a template system. For any 
particular data type, a 'Content Template' must be built. This template contains all the 
HTML form elements (and possibly ActiveX controls etc for WYSIWYG editing) to 
enable users to enter the appropriate information into the database. A second 
template (or set of templates) are then constructed in order to extract this information 
from the database and present it to the user. 

For the 'Question' example given earlier, a template would be constructed containing 
all the form input elements pertaining to a question, such as "Question Text", "Question 
Dimension" (as a dropdown list) etc. A second template (or set of templates) would 
then be used to extract questions from the database and present them to the user, 
within the context of the site. 

As well as data directly displayed in the site, it is possible to use the CPS to manage 
meta-data. This meta-data could be 'keywords' or any other parameters governing the 
web applications behaviour. For example, the CPS could present an interface for 
managing site defaults such as "Number of Questions Per Page" or "Questionnaire 
Time Limit" etc. 

Application 

We anticipate placing the following items under CPS control:- 

• All static pages (defined as pages which do not otherwise draw content from the 
database, e.g. a help page). These pages could be edited using a combination of 
HTML form input and ActiveX WYSIWYG editors. 

• All feedback strings (e.g. text from matrices for constructing customised feedback). 

• All question text and parameters (allowing CPS control over questionnaire structure 
and scales). 

• Various other parameters (e.g application defaults such as "Timelimit for Rater 
Questionnaire Completion = 21 days). 

Placing values under CPS control does not exclude them from alteration by direct 
intervention with the database but rather makes them accessible for non-database 
administrators. Furthermore, Hay will have the ability to give specific users the 
permission to alter particular parameters and pages. 
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6 Technical Infrastructure 



6.1 Estimated Server Load 

This server load is a worst-case (with respect to load) scenario projection based on the 
expected number of users for the second year of the system's lifespan. Numbers are 
not known exactly but the estimates and assumptions given are pessimistic in order to 
allow the maximum safety margin. 

Expected Usage: 47,500 questionnaires per day 

Given a window of 6 hours during which these questionnaires will be completed, this 

gives an hourly average of 7,916 questionnaires per hour. 

Assuming that each questionnaire could result in 70 HTTP requests gives a total of 

554,120 HTTP requests per hour. 

Dividing by 3,600 gives:- 154 HTTP requests per second. 

Unfortunately the HTTP requests alone does not give a good indication of server load. 
Flat HTML pages will place very low loads on the server whereas pages which make 
database queries and then perform complex operations on that data will result in much 
higher loads on memory as well as CPU. For this reason we have specified a system 
capable of handling 154 HTTP requests per second along with processing for each 
request. 

6.2 Hardware Requirements 

Two alternative solutions are suggested. The first will provide for redundancy and load 
balancing in the web server but not in the database server. The second will provide for 
redundancy and load balancing for both servers. 

All the machines described will be based on Intel processors running Microsoft 
Windows NT4.0 Server Enterprise Edition as the operating system. 
The loads described above would require some sort of multiprocessor system which 
could also have built in redundancy through the use of:- 

• Mirrored / shared RAID array of disks (for disk redundancy) 

• Use of at least two load-balanced computers (for system redundancy, load 
capacity and scalability) 

Of the two machine configurations presented below, it is anticipated that Machine 
Configuration 1 will be used initially. A single database server with a RAID level 1 
system would provide disk redundancy, minimising the risk of disk failure. 

6.2.1 Machine Configuration 1 

Web Servers - 2 machines with the following configuration: 



Procesors 


Dual Intel Pentium III Xeon processors, 800 
MHz 


Memory 


1GB SDRAM 


Disk 


10GB Ultra Wide SCSI RAID, Raid level 1 
(full redundancy.) This would require at least 
20GB per machine depending on the RAID 
configuration. 


Network Interfaces 


2 x 100Mb Ethernet controllers 


Software 


Microsoft Windows NT4.0 Server Enterprise 
Edition, Allaire Cold Fusion Enterprise Server 
4.5 
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Database Server: 



Procesors 


Dual Intel Pentium ill Xeon processors, 800 
MHz 


Memory 


1GB SDRAM 


Disk 


20GB Ultra Wide SCSI RAID, Raid level 1 
(full redundancy.) This would require at least 
40GB depending on the RAID configuration. 


Network interfaces 


2 x 100Mb Ethernet controllers 


Software 


Microsoft Windows NT4.0 Server Enterprise 
Edition, Microsoft SQL Server 



6.2.2 Machine Configuration 2 

Web Servers - 2 machines with the following configuration: 



Procesors 


Dual Intel Pentium ill Xeon processors, 800 
MHz 


Memory 


1GB SDRAM 


Disk 


10GB Ultra Wide SCSI RAID, RAID level 1 
(full redundancy.) This would require at least 
20GB per machine depending on the RAID 
configuration. 


Network Interfaces 


2 x 100Mb Ethernet controllers 


Software 


Microsoft Windows NT4.0 Server Enterprise 
Edition, Allaire Cold Fusion Enterprise Server 
4.5 



Database Servers - 2 machines with the following configuration: 



Procesors 


Dual Intel Pentium III Xeon processors, 800 
MHz 


Memory 


1GB SDRAM 


Disk 


20GB Ultra Wide SCSI RAID, RAID level 1 
(full redundancy.) This would require at least 
40GB per machine depending on the RAID 
configuration. In order to provide load 
balancing for SQL server it would be required 
that this be configured as a shared SCSI 
RAID array. 


Network Interfaces 


2 x 100Mb Ethernet controllers 


Software 


Microsoft Windows NT4.0 Server Enterprise 
Edition, Microsoft SQL Server 



6.3 Server Software Requirements 

6.3.1 Microsoft Windows NT 4.0 Enterprise Edition (patched to 
include HS4.0) 

The server's operating system, providing the basic functions necessary to access disk 
and memory etc. IIS 4.0 is Microsoft's web server. This will service HTTP (web) 
requests. 

6.3.2 Microsoft SQL Server 7.0 

Microsoft's relational database management system (RDBMS). This will provide data 
storage, indexing and retrieval services for the web application. In addition, the 
RDBMS will provide for the use of "Stored Procedures" to optimise particular algorithms 
and queries and give Hay the ability to alter these algorithms. 
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6.3.3 Allaire Coldfusion 4.5 (Enterprise Edition for Windows NT) 

Coldfusion is Allaire's server side scripting engine. It provides methods via which 
databases can be queried and updated interactively over the web (as well as a huge 
range of other functionality, independent of client browser versions). Coldfusion also 
incorporates a version of the Verity search engine as well as a version of BrightTiger 
ClusterCats load balancing software for dynamic load balancing across multiple 
machines. 

6.4 Programming Tools 

6.4.1 Overview 

The following programming languages may be used in various parts of the web 
application, although this will be an implementation issue. All languages are industry 
standards and are freely available commercially. 

6.4.2 HTML 

Hypertext Markup Language (HTML) is the language of the web. HTML is used to 
format text and layout of content in web pages. The application will use HTML as part 
of the ColdFusion templates used to render the data and images which comprise the 
front-end of the application (i.e. the web pages the end user sees). 

6.4.3 Javascript 

Javascript is a client-side scripting language. It is executed within a users browser 
rather than on the server (as ColdFusion is). It is used to add functionality such as 
mouse roll-over images. 

6.4.4 CFML 

ColdFusion Markup Language (CFML) is the language of ColdFusion. The application 
templates will be built primarily in CFML, which when executed on the server, will 
output HTML. CFML will also be used for other server side processing activities, such 
as retrieving information from the database by passing SQL statements or performing 
calculations. 



6.4.5 Java/C++/VB 

Java, C++ and VB are all high-level programming languages which may be used to 
create server-side components. 



6.5 Client Software Requirements 

The client software required to access the CPS will be Internet Explorer 4.0 and above 
with ActiveX and JavaScript enabled. The browser security settings must be such that 
ActiveX controls can be downloaded. ActiveX controls to be used will be:- 

• Ektron eWebEditPro (www.ektron.com ) 

• Broadband's Tree Control (API documentation will be provided) 

This specification is for CPS users only. General site users must conform to the 
specification laid out in "8.1 Client Specification". 

6.6 ISP Requirements 

Broadband make the following recommendations for minimum requirements which the 
ISP hosting the web application must meet. 
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6.6.1 Physical Security 

As well as controlling access to the servers (physically) the ISP should provide 
protection against power cuts and fires. Any fire prevention systems should not 
damage the hardware. Uninterruptible power supplies should be provided, probably 
with a combination of battery and generator backup. 

6.6.2 Network Security 

All machines on the internet are vulnerable to attack by hostile users. In order to 
minimise the risk of such an attack we recommend that the system be placed behind a 
firewall of some description. The firewall must prevent unknown users from accessing 
all ports other than the standard port 80 (HTTP). Authorised users should be allowed 
access to other necessary ports (either by authentication or IP). 

6.6.3 Maintenance 

The system should be placed with an ISP who undertake to repair any hardware faults 
within a specified period of time. Additionally, we recommend the use of an ISP who 
will provide the same level of support for the operating system and server software 
(excluding the web application itself). 

6.6.4 Backup 

The ISP must provide daily backup facilities for the server. Ideally a second network 
interface would be installed for backup purposes and backups should be periodically 
removed from site to protect from fire and flood. 
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7 Scalability 

This section deals with all aspects of system scalability, ranging from day to day 
modification through system upsizing to complete redeployment. 

7.1 System Modification 

Many of the algorithms described in "Functional Breakdown" will be implemented as 
stored procedures within the Microsoft SQL database. As well as providing better 
performance than ColdFusion code, this will provide Hay with the ability to modify the 
algorithms independently of the central system. This modification would be performed 
by expert database administrators. 

There are other aspects of the system that would be managed by direct access to the 
database, notably:- 

• Licences - Hay will maintain pools of valid licences for Teachers, Headteachers 
and EAs. 

• School Database - Initial input of schools, school IDs, LEAs and LEA IDs will be 
performed by Hay as part of the sales process. It is possible that a DfEE database 
will be used. 

• Population Norms - Hay will be responsible for periodic updates of the population 
norms used during the feedback process. 

All application data will be accessible to database administrators and a DBA manual 
will be provided to enable low level management of that data. 

Further changes to the system beyond data management will require ColdFusion skills 
(see "Maintainability"). 



7.2 Portability 

There are two important aspects of portability for this web application:- 

7.2.1 Platform portability 

How easy is it to move this complete system to another server/ISP? 
The biggest constraint on the system as defined is Microsoft SQL Server. This will only 
run on Windows NT and so this application could not be run without a Windows NT 
machine without incurring long redevelopment times. In contrast, the web front end will 
be implemented using ColdFusion which is available for several platforms (Solaris, NT 
and Linux supporting ClusterCats) and could thus run on a broad range of hardware. 
In fact, it is possible to mix multiple platforms within one ColdFusion cluster. 

Should it ever be desirable to move from Microsoft SQL Server, it would be necessary 
to either duplicate the stored procedure functionality in another database platform or to 
move the algorithm code into the ColdFusion templates themselves. 

Moving the system to a similar or identical hardware setup at another ISP will be a 
logistics exercise and should be relatively painless. 

7.2.2 System portability 

How easy is it to take this system and re-use the components to build another similar 
web application? 

The system will rely on four broad categories of components:- 

• Database (Microsoft SQL Server). 

• Core CPS Components (ColdFusion code and ActiveX controls used under licence 
from Broadband). 

• CPS input templates (ColdFusion code developed for and owned by the client). 

• Web output templates (ColdFusion code developed for and owned by the client). 
The front end site is capable of running without any of the CPS components being 
present and the back end can be entirely administrated via low level database access, 
although this would not be recommended. 
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In order to develop a second TransformingLearning project based on this application, 
some ColdFusion template development would be required as well as some database 
administration. If required it would be possible to either remove the CPS completely or 
to purchase a second licence for its use. 

The bulk of the work in creating a new system would be ColdFusion coding. 

Broadband will provide documentation of the API used in the CPS as well as guidelines 
for building input and output templates. 

Increased Load 

The system is being built to take advantage of the load balancing facilities within 
ColdFusion (an embedded version of BrightTiger CiusterCats). As well as providing 
redundancy (with two or more servers), this will provide for a painless upgrade path in 
terms of the system's ability to absorb unforeseen loads. The cluster system will 
enable further web servers to be dynamically added to the setup, providing further 
processing power. As mentioned above, such systems need not be NT based. 

Moving the system from a single database server to a cluster arrangement would 
involve a more complex procedure. Building a SQL cluster would involve creating a 
shared RAID setup which could involve some downtime for the existing system. It is 
anticipated that any future bottlenecks are far more likely to be found in the web 
servers than in the back end database system. 

Maintainability 

System modifications beyond database administration will involve some ColdFusion 
coding. As discussed above, the output templates are completely separable from the 
back end CPS system. 

Such modifications would include fundamental changes to the processes involved in 
the application (as described in "Functional Breakdown") beyond parametric changes 
and changes to algorithms (which are implemented as stored procedures). 



The following table gives examples of a few system modifications and at what level 
these modifications would have to take place:- 



Modification 


Level 


Changing text of a question 

. ' '< , , ■ 


CPS or database admin 


Modifying a static page 


CPS or database admin 


Changing a parameter within an 
algorithm 

Changing an algorithm (e.g. adding 
extra conditions) 


CPS or database admin 

Database admin (editing stored 
procedures) 


Modifying the login process to 
accept and correctly process a new 
user type 


ColdFusion code 


Modifying the feedback process to 
force users to view each page for at 
least one minute before moving on 


ColdFusion code 
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8 Scope 

8.1 Client Specification 

We will ensure that the site is fully accessible in all common web browsers, specifically 
Netscape 3.0+ and Internet Explorer 3.0+ on PC and Macintosh. We will work to a 
baseline screen resolution of 640x480 and colour depth of 256 colours. We will 
assume that users have JavaScript enabled in their browsers, but pages will degrade 
gracefully in so far as is possible to accommodate those users who do not. As a worst 
case scenario, the user will be directed to a page telling them that they need to enable 
JavaScript. We will not assume users have any browser plugins, and for this reason 
Flash will not be used anywhere on the site. 

8.2 Phase Two 

TLC and Broadband to decide which functionality will be not be available until Phase 
Two, and to formulate a strategy for how Phase Two components will be enabled. 
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9 Appendices 

9.1 Appendix 1 - Demo Site Map 
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Appendix 2 - Demo Site Content 
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9.3 Appendix 3 - List of Algorithms 



• QBb1 - Headteacher climate validation algorithm 1 

• QBb2 - Headteacher climate validation algorithm 2 

• QBb3 - Headteacher climate validation algorithm 3 

• QBb4 - Headteacher pair check algorithm 

• QBa2 - Headteacher leadership validation algorithm 2 

• QBa3 - Headteacher leadership validation algorithm 3 

• QAc7 - Algorithm for questions to display - Primary teacher 

• QBc2 - Primary teacher validation algorithm 2 

• QBc3 - Primary teacher validation algorithm 3 

• QAd7 - Algorithm for questions to display - Secondary teacher 

• QBd1 - Secondary teacher climate validation algorithm 1 

• QBd2 - Secondary teacher climate validation algorithm 2 
« QBd3 - Secondary teacher climate validation algorithm 3 

• QBd4 - Secondary teacher pair check algorithm 

• QBf2 - Adult rater climate validation algorithm 2 

• QBf3 - Adult rater climate validation algorithm 3 

• QBf4 - Adult rater pair check algorithm 3 

• QBe2 - Adult rater leadership validation algorithm 2 

• QBe3 - Adult rater leadership validation algorithm 3 

• QAg1 - Algorithm for questions to display - Primary student rater 

• QBg2 - Primary student rater validation algorithm 2 

• QBg3 - Primary student rater validation algorithm 3 

• QAh1 - Algorithm for questions to display - Secondary student rater 

• QBh2 - Secondary student rater validation algorithm 2 

• QBh3 - Secondary student rater validation algorithm 3 

• QCf3 - Adult rater climate reversals check 
© QCf1 - Adult rater climate scale check 

• QCf2 - Adult rater climate blank check 

• QCe1 - Adult rater leadership scale check 

• QCe2 - Adult rater leadership blank check 

• QCg1 - Primary student rater scale check 

• QCg2 - Primary student rater blank check 

• QCh3 - Secondary student rater reversals check 

• QCh1 - Secondary student rater scale check 

• QCh2 - Secondary student rater blank check 

• QDb1 - Headteacher reverse climate questions 

• QDb2 - Headteacher calculate climate self dimensions 

• QDa1 - Headteacher reverse leadership questions 

• QDa2 - Headteacher calculate leadership self dimensions 

• QDa3 - Headteacher calculate leadership percentiles 

• QDc1 - Primary teacher reverse climate questions 

• QDc2 - Primary teacher calculate climate self dimensions 

• QDd1 - Secondary teacher reverse climate questions 

• QDd2 - Secondary teacher calculate climate self dimensions 

• QDft - Adult rater reverse climate questions 

• QDf2 - Adult rater calculate climate self dimensions 
« QDe1 - Adult rater reverse leadership questions 

• QDe2 - Adult rater calculate leadership self dimensions 

• QDe3 - Adult rater calculate leadership percentiles 

• QDg1 - Primary student rater reverse questions 

• QDg2 - Primary student rater calculate self dimensions 

• QDh1 - Secondary student rater reverse questions 

• QDh2 - Secondary student rater calculate self dimensions 

• QEft - Adult rater climate calculate dimension spread 

• QEf2 - Adult rater climate calculate dimension average 
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QEf3 - Adult rater climate calculate dimension spread index 
QEf6 - Adult rater climate test for ORL per dimension 
QEf7 - Adult rater climate test for rejection 

QEf9 - Adult rater climate count ORL for rater and flag rater if outlier and if > z 

QEf5 - Adult rater climate dimension validity check 

QFf1 - Adult rater climate recalculate calculable dimensions 

QFf2 - Adult rater climate recalculate spread index 

QFf4 - Adult rater climate check for agreement per-dimension and flag 

QEe1 - Adult rater leadership calculate style spread 

QEe2 - Adult rater leadership calculate style average 

QEe3 - Adult rater leadership calculate style spread index 

QEe6 - Adult rater leadership test for ORL per style 

QEe7 - Adult rater leadership test for rejection 

QEe9 - Adult rater leadership count ORL for rater and flag rater if outlier and if > z 

QEe5 - Adult rater leadership style validity check 

QFe1 - Adult rater leadership recalculate calculable styles 

QFe2 - Adult rater leadership recalculate spread index 

QFe4 - Adult rater leadership check for agreement per-style and flag 

QFe3 - Adult rater leadership calculate percentiles per style 

QEg1 - Primary student rater calculate dimension spread 

QEg2 - Primary student rater calculate dimension average 

QEg3 - Primary student rater calculate dimension spread index 

QEg6 - Primary student rater test for ORL per dimension 

QEg7 - Primary student rater test for rejection 

QEg9 - Primary student rater climate count ORL for rater and flag rater if outlier and if > z 

QEg5 - Primary student rater dimension validity check 

QFg1 - Primary student rater recalculate calculable dimensions 

QFg2 - Primary student rater recalculate spread index 

QFg4 - Primary student rater check for agreement per-dimension and flag 

QEh1 - Secondary student rater calculate dimension spread 

QEh2 - Secondary student rater calculate dimension average 

QEh3 - Secondary student rater calculate dimension spread index 

QEh6 - Secondary student rater test for ORL per dimension 

QEh7 - Secondary student rater test for rejection 

QEh9 - Secondary student rater climate count ORL for rater and flag rater if outlier and if 
>z 

QEh5 - Secondary student rater dimension validity check 

QFh1 - Secondary student rater recalculate calculable dimensions 

QFh2 - Secondary student rater recalculate spread index 

QFh4 - Secondary student rater check for agreement per-dimension and flag 

QGb1 - Calculate AS-IS gaps (Headteacher & adult rater) 
QGb5 - Mark AS-IS gap (Headteacher & adult rater) 
QGb2 - Calculate AR-IR gaps (Headteacher & adult rater) 
QGb6 - Mark AR-IR gap (Headteacher & adult rater) 
QGb3 - Calculate AS-AR gaps (Headteacher & adult rater) 
QGb7 - Mark AS-AR gap (Headteacher & adult rater) 

QGb4 - Derive climate score markers per-dimension (rater only) (Headteacher & adult 
rater) 

QGa1 - Leadership score markers - self (Headteacher & adult rater) 
QGa2 - Leadership score markers - raters (Headteacher & adult rater) 
QGa3 - Calculate self - rater leadership gaps (Headteacher & adult rater) 
QGa3 - Mark self - rater leadership gaps (Headteacher & adult rater) 
QGb8 - T2 calculate AS-ASH gaps (Headteacher & adult rater) 
QGb10 - 12 mark AS-ASH gaps (Headteacher & adult rater) 
QGb9 - 12 calculate AR-ARH gaps (Headteacher & adult rater) 
QGb1 1 - 12 mark AR-ARH gaps (Headteacher & adult rater) 
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• QGb12 - 12 calculate (AS-AR) - (ASH-ARH) gaps (Headteacher & adult rater) 

• QGb1 3 - T2 mark (AS-AR) - (ASH-ARH) gaps (Headteacher & adult rater) 

• QGa6 - T2 Calculate self(1 ) - self(2) leadership gaps (Headteacher & adult rater) 

• QGa7 - 12 Mark self(1 ) - self(2) leadership gaps (Headteacher & adult rater) 

• QGa8 - T2 Calculate rater(1 ) - rater(2) leadership gaps (Headteacher & adult rater) 

• QGa9 - T2 mark rater(1 ) - rater(2) leadership gaps (Headteacher & adult rater) 

• QGc1 - Calculate AS-AR gaps (Primary teacher & primary student rater) 

• QGc3 - Mark AS-AR gap (Primary teacher & primary student rater) 

• QGc2 - Derive climate score markers per-dimension (rater only) (Primary teacher & 
primary student rater) 

• QGc4 - T2 calculate AS-ASH gaps (Primary teacher & primary student rater) 

• QGc6 - 12 mark AS-ASH gaps (Primary teacher & primary student rater) 

• QGc5 - T2 calculate AR-ARH gaps (Primary teacher & primary student rater) 

• QGc7 - T2 mark AR-ARH gaps (Primary teacher & primary student rater) 

• QGc8 - T2 calculate (AS-AR) - (ASH-ARH) gaps (Primary teacher & primary student 
rater) * 

• QGc9 - T2 mark (AS-AR) - (ASH-ARH) gaps (Primary teacher & primary student rater) 

• QGd1 - Calculate AS-IS gaps (Secondary teacher & secondary student rater) 

• QGd5 - Mark AS-IS gap (Secondary teacher & secondary student rater) 

• QGd2 - Calculate AR-IR gaps (Secondary teacher & secondary student rater) 

• QGd6 - Mark AR-IR gap (Secondary teacher & secondary student rater) 

• QGd3 - Calculate AS-AR gaps (Secondary teacher & secondary student rater) 

• QGd7 - Mark AS-AR gap (Secondary teacher & secondary student rater) 

• QGd4 - Derive climate score markers per-dimension (rater only) (Secondary teacher & 
secondary student rater) 

• QGd8 - 12 calculate AS-ASH gaps (Secondary teacher & secondary student rater) 

• QGd10 - 12 mark AS-ASH gaps (Secondary teacher & secondary student rater) 

• QGd9 - 12 calculate AR-ARH gaps (Secondary teacher & secondary student rater) 

• QGd1 1 - 12 mark AR-ARH gaps (Secondary teacher & secondary student rater) 

• QGd12 - 12 calculate (AS-AR) - (ASH-ARH) gaps (Secondary teacher & secondary 
student rater) 

• QGd 1 3 - 12 mark (AS-AR) - (ASH-ARH) gaps (Secondary teacher & secondary student 
rater) 

• TF1 & TF1(2) Secondary teachers Order of Chart Presentation 

• TF2a & TF2a(2) Secondary teachers Gap and Absolute Level Analysis - per 
dimension 

• TF2b &TF2b(2) Secondary teachers Gap and absolute levels analysis - across 
dimensions 

• TF3 & Too Many Bad Reactions? 

• TF4 Is Data Dodgy? 

• TF5 Produce Priority Matrix (Dkl) 

• TF6 Produce Investigate Matrix (Similar to TF5) 

• TF7 Chance of Success 

• TF8 Have They Chosen Any Improvement Areas? 

• TF9 Relationship between priority and attitude 

• TF12 Primary teachers order of chart presentation 

• TF13a Primary teachers gap and absolute level analysis - per dimension 

• TF13b Primary teachers gap and absolute level analysis - across dimension 

• TF14 & TF14(2) Primary - is data dodgy? 

• HF1 & HF1(2) Order of climate chart presentation 

• HF2a & HF2a(2) Gap and absolute levels analysis - climate dimensions 

• HF2b & HF2b(2) Gap and absolute levels analysis - overall climate 

• HF3 Too many bad reactions? 

• HF4 Is data dodgy? 

• HF5 & HF5(2) Order of presentation of styles charts 

• HF6a & HF6a(2) Gap and absolute levels analysis - phases styles 

• HF6b & HF6b(2) Gap and absolute levels analyis - styles comparison 
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• HF7 Identify HT's effective styles per priority dimension 

• HF8 Determine what level style is displayed at 

• HF9 Produce emotions matrix 

• HF10 Produce priorities matrix 

• HF11 Chance of success algorithm 

• HF12 & HF12(2) Was reaction to styles emotional? 

• HF13 Build on strengths (time 2 only) 

• HF14 What was level of style and difference vs previous measurement? (time 
2 only) 

• EA1 Produce table of subjects available 

• EA2 Produce school average chart 

• EA3-EA17 Produce subject charts 

• EA18 Produce table of key stages available 

• EA19-21 Produce key stage charts 

• EA24 Produce group secondary average chart 

• EA25 Produce group primary average chart 

• EA26 Produce table of schools available 

• EA27 Calculate average of the average rater scores (ie. each set of raters has 
weighting of 1) 

• EA28 Find the minimum of the average rater scores 

• EA29 Find the maximum of the average rater scores 

a EA30 Calculate the historical average of the average rater scores 

• EA31 Calculate the gap - Average-AverageH 

• EA32 Mark the gap - Average-AverageH - 5 types - secondary 

• EA33 Calculate average of the average rater scores (ie. each set of raters has 
weighting of 1) 

• EA34 Find the minimum of the average rater scores 

• EA35 Find the maximum of the average rater scores 

• EA36 Calculate the historical average of the average rater scores 

• EA37 Calculate the gap - Average-AverageH 

• EA38 Mark the gap - Average-AverageH - 5 types - secondary 

• EA39 Calculate average of the average rater scores (ie. each set of raters has 
weighting of 1) 

• EA40 Find the minimum of the average rater scores 

• EA41 Find the maximum of the average rater scores 

• EA42 Calculate the historical average of the average rater scores 

• EA43 Calculate the gap - Average-AverageH 

• EA44 Mark the gap - Average-AverageH - 5 types - primary 

• EA45 Calculate average of the average rater scores (ie. each set of raters has 
weighting of 1) 

• EA46 Find the minimum of the average rater scores 

• EA47 Find the maximum of the average rater scores 

• EA48 Calculate the historical average of the average rater scores 

• EA49 Calculate the gap - Average-AverageH 

• EA50 Mark the gap - Average-AverageH - 5 types - secondary 

• EA51 Produce table of schools that have registered 

• SMI Produce table of subjects available 

• SM2 Produce school average chart 

• SM3-SM17 Produce subject charts 

• SM18 Produce table of key stages available 

• SM 1 9-23 Produce key stage charts 

• SM24 Calculate average of the average rater scores (ie. each set of raters has 
weighting of 1) 

• SM25 Find the minimum of the average rater scores 

• SM26 Find the maximum of the average rater scores 

• SM27 Calculate the historical average of the average rater scores 

• SM28 Calculate the gap - Average-AverageH 
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• SM29 Mark the gap - Average-AverageH - 5 types - primary 

• SM30 Mark the gap - Average-AverageH - 5 types - secondary 

• SM31 Calculate average of the average rater scores (ie. each set of raters has 
weighting of 1) 

• SM32 Find the minimum of the average rater scores 

• SM33 Find the maximum of the average rater scores 

• SM34 Calculate the historical average of the average rater scores 

• SM35 Calculate the gap - Average-AverageH 

• SM37 Mark the gap - Average-AverageH - 5 types - secondary 

• SM38 Calculate average of the average rater scores (ie. each set of raters has 
weighting of 1) 

• SM39 Find the minimum of the average rater scores 

• SM40 Find the maximum of the average rater scores 

• SM41 Calculate the historical average of the average rater scores 

• SM42 Calculate the gap - Average-AverageH 

• SM44 Mark the gap - Average-AverageH - 5 types - secondary 
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Appendix 4 - Process Flow Charts 
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9.5 Appendix 5 - Entity Relationship Diagrams 
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Appendix 6 - Alpha and Beta Checklist 
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9.7 Appendix 7 - Scheduled Events 
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